Rock Raider Menu System 


There are a number for reasons starting this now. 


Politically: 


There are large number of non-technical people at Lego who will judge the 
game by appearances. E.g Mark Livingstone, Petra, Connie etc. If they feel confident 
that the game is progressing, then we are more likely to get the current work that they 
are offering us. If they see that 1/3 of the game is not there, particularly the first 1/3 of 
the game that children see, (the attract mode) is not even properly attempted by 
Alpha, they may decide to put a hold on the other work — until we catch up!. The fact 
that the programming of this is trivial will be besides the point, they will judge what 
they see. If the style, size, colours, ease of use and visual understanding all come 
within the Lego philosophy etc. they will still feel that we have this close synergy 
with them. You may argue that if we get it wrong, they may want changes but I would 
rather they feel that they have plenty of time to do these modifications and get the 
appropriate feedback. If they don’t like it when presented at the project end then they 
will feel they have been sold a lemon, because it did not fit their criteria and they 
can’t even put it on the shelves. They put all 3 Lego games out on the shelves in 
November as scheduled. The games may be cut down versions but they made the 
shelves. 


Personal Relationship: 


We have promised Tom that he will have Alpha by the end of this month. This 
stipulation demands that we have the front-end on. It does not mean that all the 
playability has to be in it. By missing this deadline we will put him in a bad 
position with Lego and he will then cycle into reverse demanding daily/weekly 
updates in order to cover his ass. This is already starting to happen as even 
though, he knows we are pushing for Alpha he wants an Alpha scheduled report 
by the end of this week. (He will turn into Andy from Eidos and his visits will be 
more frequent and less friendly). 


Programmer Time Impact 


We do not have to spend much of Paul or Rob’s time as this is a separate module, 
which we can integrate. Scott Williams, Tony Stoddart or even Karl (god help us) 
could be used. There will be teething problems, re CE but I am sure that a separate 
Front-end that would be far better, than no-front-end till the end of the project. 
This front-end merging would happen only once rather than multiple times when, 
at the end they would keep asking for changes that could have been ironed out 
much earlier. 


We do have more available artist time, which could be utilised for BMP’s even 
Avi’s etc. to gain much of the info we need. I am not suggesting huge FMV’s but 
mockups could be submitted for approval. 


The Age-Range 


This game is for 7-10 year olds and to be confident that this age range can play the 
game, it must be suitably tested on this range. Focus testing will require time and if 
we hand them an almost ‘finished’ game before we do the front-end they will surely, 
hold any bad publicity on the ‘ease of use’ against us. If I could turn back time to CE 
and have just | month to change things, it would only be to listen to what the 
Americans, Germans and British reviewers were telling us. Apart from gameplay 
issues their biggest problems were: 


i.e. 

Make the game easier to get into (menu wise) 

Have a simple control method 

Make it easier to understand what the icons mean and what you have to do. 


By getting feedback on these issues early enough we can avoid some of the pitfalls we 
hit with CE. Our attitude was wrong, we did a game for us and not a game that the 
public wanted. We should have listened to the feedback and adjusted accordingly, but 
as we got our feedback so late in the development process, it was too late to do 
anything about it. 


Value of Early Focus Testing 


Lego has a lot to say about the style of the game and take a very long time to decide 
what colour a hat should be. They no doubt have focus test results that will favour one 
colour as opposed to the next. There is no doubt strong financial reasons for doing this 
depth of testing. 


Information that would be useful for us to know when developing a menu system. 


What colours did the kids like that was offered, that still fits in with the style of the 
game. Is the style too hard for the kid to differentiate between foreground and 
background colours. 


What is a suitable size Icon for a 7 year old, does he find clicking on a 16x16 icon 
ergonomically frustrating. Is that size of icon too small and unappealing in terms of 
the graphic picture, so that he loses interest. Would he feel happier with a 24x24 or 
32x32 that is spread over two screens. 


What font and size is readable for a 7 year old. Perhaps a monochromatic colour is 
readable for him, but he will not read it because it is not pretty and he will then miss 
valuable information leading him to the conclusion that the game is hard. Perhaps 
pretty coloured fonts are attractive but too difficult to read. 


What style of control method should we use. Horizontal scrolling or do they prefer 
Vertical scrolling, or typing in numbers or using counters. Maybe they can click the 
ends of the scroll bar arrows but do not realize about dragging the middle box section. 


Are kids better at looking at a non moving static screen or could we use a 3D ‘piston’ 
type scroll bar instead of a flat one. 


What text words does a kid understand, can we use ‘Ambience’ or is there a simple 
alternative, perhaps graphically demonstrated. 


What size, shape, particularly position, colour should the Exit buttons, ‘Go back’, ’Go 
forward’ be. That would still fit in with the style. 


Should we have a ‘Captain’ Advisor for the help screens as well. Perhaps he could 
appear beside each option giving information or should we use just a text tip info and 
audio or leave it like other games. Such and easy menu system could be hailed as 
great by Lego, but if left to the end will never happen. 


As we experiment through the menus system we will find features, we would like to 
implement e.g. reset default settings, save settings etc. There will be others as we 
develop the game but this is better being found sooner rather than patching it in later. 


Are kids better at sub menus or would they prefer more crammed screens but not sub- 
menus. 


Conclusion 


Taking into account all of the points above will help give us a tried and tested menu 
system that will be bug-free (until merging), be approved and liked by Lego and be 
easy for the kids to understand. If written flexibly, additions, changes etc, can be 
added with little detriment. 


Our greatest resource is the artists, who do not do things right first time and generally 
need a lot of corrections. We had the exact in-game models since April and I still find 
fault/ enhancements to them. It took 6 attempts to get the style of the in-game ‘button’ 
right and almost 2 months for Tom to confirm that was the style he was after. He will 
not be happy to approve anything that has not gone through Billund, focus testing etc. 
but will loudly blame us for any synergy problems that may arise. Also, by giving him 
things to approve, it keeps him occupied and gives us excuses should we need them. 


IF CE had 95% reviews sold 500,000 copies but was several months late, they would 
have forgiven us. Instead it was slated for the control method, ease of use and the 
most unforgivable confusing menu system created. (Matt Miller) 


